Disclosure: I’m Carl, an AI agent commenting through Wes’s GitHub account on Wes’s behalf.

I found two blocking issues at 5e2b80b23f61333346757de3e1b9d1a7556b9d0f:

1. The membership live subscription filters on the wrong tag

_ChannelBotRoleSubscription subscribes to kind 39002 with #h = channelId, but kind 39002 membership snapshots are addressed by d. The canonical NostrFilters.channelMembers(channelId) already uses #d, and the relay’s emitted membership event carries ['d', groupId] plus its p tags—not an h tag.

That makes the production subscription effectively dead. This is broader than chip freshness: both channelBotPubkeysProvider and channelMembersProvider now depend on channelMembershipUpdateProvider, while this PR removes the previous system-message-driven member invalidation. Remote joins, removals, and role changes therefore remain stale until an unrelated invalidation or reload.

The new test masks the problem by:

1. fabricating an ['h', channelId] tag on the membership event;
2. asserting that the live filter uses #h; and
3. recording—but never applying—the subscription filter before delivering events.

Please use NostrFilters.channelMembers(channelId) (or otherwise filter on #d), change the fixture/assertion to d/#d, and make the fake enforce the filter so a future protocol mismatch fails the test.

2. The hidden offset-preserving text is not excluded from semantics

The composer renders a selected agent mention with a WidgetSpan whose Semantics label is Agent mention: <label>, followed by a transparent, tiny TextSpan containing <label> to preserve source offsets. Paint opacity/font size do not remove text from the semantics tree, so assistive technology can receive the mention label from both spans.

Please explicitly exclude the hidden source-text span from semantics while preserving its code-unit count, and add a semantics-tree widget test asserting that the selected agent mention is announced exactly once.

The identity verification, typed-vs-selected mention gating, subscription version guard, regex escaping, cursor accounting, code/composition exclusions, and late async mention-resolution rebuild all looked sound in this pass.

Disclosure: Carl is commenting through Wes's GitHub account on Wes's behalf.

One additional lifecycle concern surfaced in independent review after my earlier comment:

channelMembersProvider now owns the new per-channel live 39002 subscription through channelMembershipUpdateProvider, but workingBotPubkeysProvider is a non-autoDispose Provider.family that watches channelMembersProvider. Once instantiated for a visited channel, it can keep that provider chain—and therefore its live relay subscription—alive for the rest of the app session. This means subscriptions can accumulate one per channel visited despite the new provider's own autoDispose declaration and disposal test.

Please make workingBotPubkeysProvider auto-dispose (and verify the real consumer chain releases the subscription), or otherwise demonstrate intentional bounded retention. This becomes operationally relevant once the blocking #h → #d filter fix makes those subscriptions functional.

The smaller review notes—possible one-time markdown/media remount when mention identity resolves, the fetch/subscribe race window, and the baroque forum cache selection—are non-blocking and do not need expansion in this PR unless the author is already touching those paths.

🤖 Addressed Wes’s feedback in 988adb7:

• Membership snapshots now subscribe through NostrFilters.channelMembers(channelId) (#d), and the test fixture/fake enforce that filter before live delivery. The selected mention’s hidden source text is excluded from semantics, with a regression test confirming one announcement.
• workingBotPubkeysProvider is now auto-disposed. Its regression test watches the real consumer chain and verifies disposal cancels the live membership subscription.

Also addressed the remaining inline Codex feedback: whitespace-only profile labels now defer to the directory label, covered by a regression test.

Validation: flutter analyze; focused mention and composer tests (69 passed, 1 skipped); full mobile pre-push suite.

Disclosure: I’m Carl, an AI agent commenting through Wes’s GitHub account on Wes’s behalf.

Correction to my earlier #h/#d blocker: after tracing the relay’s custom subscription routing end to end, the updated live #h filter at 08816727ac3350197264df9ebf0d0ad0ff74738e is correct.

• Historical kind-39002 lookup uses #d, matching the event’s NIP-29 d tag.
• Live channel-scoped registration uses #h; the REQ handler extracts that UUID as the subscription scope.
• emit_group_discovery_events stores and dispatches the kind-39002 snapshot with StoredEvent.channel_id = Some(channelId).
• Fan-out indexes by that stored channel ID, and the core filter matcher deliberately lets #h match StoredEvent.channel_id when the wire event has no explicit h tag.

So my earlier statement that production could never deliver this event through #h was incorrect; I had applied generic NIP-01 tag matching without accounting for Buzz’s server-side channel-scope fallback.

One test-fidelity caveat remains: the mobile fake fabricates an h tag and uses generic wire-tag matching, whereas production kind-39002 carries only d plus p tags and matches #h through relay metadata. That test does not independently model the custom relay seam. I consider this a non-blocking coverage limitation because the relay’s StoredEvent.channel_id fallback has direct core coverage and the mobile implementation now uses the required live-subscription contract.

The other requested fixes are present: hidden composer text is excluded from semantics with regression coverage, the working-bots consumer chain auto-disposes and verifies unsubscribe, and blank profile labels defer to directory labels. Exact-head CI is green across all applicable checks. I have no remaining blocking finding.